Kotlin coroutine
が、進化して、単純なthread poolから、構造化された(CoroutineScope)実行フロー(cancelの管理)ができるようになった。
coroutine の 中断が生じるということを意識しないと、わかってこない。
suspend (resume)を制御するのは他の言語と同じ?
中断を起こせる状況(中断を起こすために必要条件)
coroutineScopeの中でのみ。CoroutineScope#launch{} の中と、runBlocking{}の中
中断を起こせるのは、
suspendな関数を呼んだ時
withContext(){}を呼んだ時
async{}で受け取ったdefferredをawaitした時
CoroutineContext
このCoroutineContextのcontextで実行される。
The coroutine context is a set of various elements. The main elements are the Job of the coroutine, which we've seen before, and its dispatcher, which is covered in this section.
jobとdispathcerで構成される要素。なので、dispatcherは何で、jobはどれということを意識すればよい。はず。
メソッドに plus, minus, fold(accumulate)があり、context要素を代数的に扱える??
jobが加算されるとは、stackに対して、積み降りするようなもの?
60%くらい分かってきた。もう少し。
coroutine1つに対応するthread?
threadの分類は Main, Default(worker), IOなどがあるので、coroutineのthreadは、これらのどれかと親子関係を結ぶ?
dispatherは、上記の大分類のどれに投げるかを指定する。
thread分類とは別に、名前空間による整理もあり、それが CoroutineのScope
ただ、thread分類は又ぐ事はできない。
coroutineの実体は、jobオブジェクトになる。
Job()で生成できる。
GlobalScopeという予め生成された jobもある。
Jobのメソッドで、launch, asyncがあり、これでcoroutineが動き出す。
launch, asyncは、 taskを返すので、task
が読めるようになるのが目標
説明がわかりやすそう。最後までよめてないけど。 RxJavaとの対比で書かれてる Dispatchersは、以下の3つがある。Main, Default, IO
メインスレッドとデフォルト(ワーカー)スレッドの振り分け
2つのAPIを順に叩く、並列で叩いて待ち合わせと、よくあるケースの紹介
GlobalScope.launch(Dispatchers.X){}
ところで、GlobalScope.launch を使う場合、生存期間はアプリ終了までになります
そのためラムダの処理が終了しない場合は、アプリの終了までインスタンスが生存し続けることになってしまいます
runBlocking{}
runBlocking は現在のスレッドをブロックするため、コルーチンとスレッドの境界でしか使用すべきではありません。
Error Handling
val job = SupervisorJob() を使う
参考:
firebaseも、referenceをget()したものをawait() すればよい? #TODO201908 The most interesting thing is that a thread can stop executing a coroutine at some specific “suspension points”, and go do some other work. It can resume executing the coroutine later on, or another thread could even take over.
suspending functions
coroutine scope